作者：Alastair GreenFollow是Neo4j的查询语言标准和研究负责人。
GQL是官方标准。今年6月，隶属ISO/IEC联合技术委员会1（负责制定IT标准）的全球诸多国家性标准机构开始就GQL项目提案进行表决。上周初投票结束，该提案获得了通过，七个国家派出专家开展这个为期四年的项目。GQL的全称是“图形查询语言”。这种新语言将由监管SQL标准的同一个国际工作组开发和维护。GQL高度依赖现有的语言。主要灵感源自Cypher（现在实现的版本有十多个，包括六款商业产品）、Oracle的PGQL和SQL本身，以及用于只读属性图查询的SQL新扩展。Tigergraph的GSQL虽然来自风格上与其他标准机构不一样的起点，但它是另一个值得注意的贡献，其开发者已对GQL项目表示出了坚定承诺。自SQL项目启动以来已有三十多年，它最初是一项ANSI标准：GQL是SQL之后的第一个ISO/IEC国际标准数据库语言项目。十个国家投票支持这个新项目：中国、韩国、瑞典、美国、德国、英国、荷兰、丹麦、哈萨克斯坦、加拿大和芬兰。五个国家因缺乏判断或评论该提案的专长而弃权。只有日本投了反对票。日本给出的评论饶有意思。他们提出了两个理由：外界的现有语言已经取得所需的结果；具体来说，SQL/属性图查询（PGQ）扩展与SQL标准的其余部分一起就能满足需求。我想谈谈为什么GQL的拥护者提议与SQL共存的一种新标准语言是对的。我在2018年5月提出了GQL宣言（GQL Manifesto）。该倡议的直接原因是：a）SQL/PGQ仅限于只读查询，b）它无法投射新图形，c）它只能访问基于生成SQL表的图形化视图的图形。但许多供应商、研究人员和用户都一致认为，可以使用非关系型“图形原生”存储和运行时模型（比如Neo4j领先行业的产品或新的Redis Labs图形产品）来开发图形数据库。他们绝对需要一种Cypher之类的语言可以支持数据的插入和维护，而不仅仅是数据查询。而SQL不太可能成为以图形为中心的可“基于图形生成”的语言所需的那种合适的模型。基于图形生成是指获取作为查询输入的图形，因而输出图形，就像SQL可以读表，并生成实为新表的结果集。支持GQL项目的许多公司和国家性标准机构并不将GQL和SQL视为竞争对手，而是视为可以通过共同基础和互操作性来相辅相成的语言。我这里所说的基础是指核心数据类型和形成表达式的方法，以及共同的概念（比如目录中保存的模式对象以及用户/角色关联的会话。）SQL/PGQ查询实际上是包裹着一段“proto-GQL”的SQL子查询。我在下面演示的一个示例查询来自关于SQL/PGQ的非常出色的资料（http://wiki.ldbcouncil.org/download/attachments/106233859/ldbc_tuc_2019_sql-pgq.pdf?version=1&modificationDate=1562342465000&api=v2）；今年SIGMOD大会接近尾声时，Oracle的同仁Oskar van Rest为7月份在阿姆斯特丹召开的链接数据库基准委员会（LDBC）会议制作了该资料。以关键字MATCH开头的红色部分是模式匹配查询的一个片段，它与用Cypher或PGQL编写的查询极其类似（这些语言在很多方面非常相似）。你可能注意到，IS用于引入标签（如在Creator IS Person中），：用于引入主机参数或变量。但是你也可以在标签表达式中使用冒号（如果SQL引擎的解析器足够智能），那样与之前存在的“输入”属性图查询语言的相似性会变得更明显。PGQ查询的其他部分（黑色和绿色）将此proto-GQL联合到SQL SELECT语句中。表格结果通过COLUMNS子句流出到常规SQL查询中。它们仅仅对与图形查询交互的SQL引擎而言值得关注。GQL本身不会参与这种SQL“外来函数接口”。模式匹配只读子语言（上面Oskar的示例查询中标以红色）注定要成为完整CRUD GQL的一个组成部分。它好比是“GQL火箭的第一级”。这种紧密的连接是GQL项目提案文件的一部分。因此，GQL的其中一项工作是规范诸多方面，比如属性图数据模型、标签的使用以及查询谓词（query predicate）的属性：我们获得了一种标准的方法来处理已经可以用现有语言来处理的事情。我们希望由多种类似语言变成一种标准语言。但我们还希望将供应商正竭力开发的工业创新成果纳入到定义清晰的属性图数据库这个产品类别?6?7。SQL/PGQ领域有值得关注的新动向，比如常规路径查询、嵌套路径和路径宏命令，所有这些都增强了流行的模式匹配范式的功能。GQL会添加还没有被所有供应商实施，但起码被至少一家供应商实施的其他创新。这就引出了SQL/PGQ无力实现、而且不太可能实现的功能。SQL这种语言在一个关键方面与Cypher大不相同。Cypher（和PGQ的图形子语言）让用户可以探索其数据图的结构，无需事先知道将返回哪些类型的数据。它们让你可以进行真正的图查询，这方面值得关注的不仅仅是值，还有数据子集的形状，在与图模式匹配的元素值方面予以定义。换句话说，图查询描述了针对一个或多个输入图计算的子图或投射图。然而，SQL/PGQ、Cypher和PGQL只允许你从图中提取一个表。这是必须保留的重要特性，因为否则就不可能获取存储在图元素上的实际数据值。但是将结果仅限于表意味着你无法轻松创建图转换链，也无法针对多个输入图执行集合操作。你也无法生成和存储快照图，无法定义图投射视图。GQL将建立在openCypher Morpheus的基础上（后者将Cypher引入到Apache Spark），并结合来自LDBC的G-CORE的灵感，为用户提供了一种组合图查询语言，支持所有那些功能。这将使GQL在概念上等同于SQL。我认为SQL标准社区在这里做出了一个正确的决定：让SQL（一种围绕表构建的语言）可以在SQL用户想要从图中查找和投射表时可以引用GQL，但在用户想要从图中查找和投射图时可以使用GQL。这意味着我们可以生成图、将图编入目录，这些图不仅仅是基于表的视图，还有离散的复杂数据对象。插入、更新和删除图（以及路径和元素）的DML语句与用于匹配和提取数据的DQL密切相关。因此，最好在这两种操作中使用一套共享的以模式为中心的词汇表。这意味着GQL是适合将“CUD”添加到PGQ的“R”的（单一）环境。你可以更新图视图下的表以获得同样的效果（前提是你使用配备图的SQL引擎），但这使你无法享用图数据模型的简单性和强大功能。这就像通过针对所有基本表编写更新来写入到SQL视图：有可能做到但弄巧成拙。由于除了SQL/PGQ中完成的工作外，GQL还添加了数据修改，我们开发了一种“可引用性更强”的GQL。如果SQL用户想要将数据从表格数据库推送到存储在数据库目录中的图对象，那么合乎自然的做法是引用更多的GQL，在SQL GRAPH_MODIFY函数里面执行专门针对图的那项工作。当我们Neo4j早在2017年在关于PGQ的标准讨论中首次提出“SQL引用Cypher”供讨论时，得到的评论是“Cypher不是一项可引用的国际标准”。这促使我们直奔GQL。它将是一种官方的国际标准，可以被SQL引用。当然，随着时间的推移，我们可能希望让GQL可以为表操作引用SQL！这引出了SQL不适合的另一项主要功能。图的类型是其节点的类型，加上边缘的类型以及它们可以连接的节点的类型。特定类型的节点和关系存储数据值：特定类型的标签和属性（内容）。SQL没有这个进化的概念：按照类型组合和参数化表示复杂类型。而表示图类型的最自然方式是显示它编码的数据关系的模式。使用元素内容（标签和属性）的“记录类型”定义的属性图形类型应运而生，模式用于将那些内容类型组合到节点和关系（包括方向）。下图是一项Neo4j提案，尚未得到一直在为GQL项目做准备的工作组的同意，但它肯定会让人想到ASCII码绘图中简洁、富有表现力的图案如何有助于记录和直观显示图及其类型。顺便说一下，GQL很可能规范无向关系的模式、查询和修改（PGQL和Tigergraph的GSQL中已经存在的一项功能）。更宽泛说，GQL让我们有机会获得比SQL更现代化的语言，拥有更结构化的类型系统、干净地组合作为过程查看的查询，拥有参数（允许参数化视图）以及前向（线性）和嵌套过程组合。我最后阐述GQL有别于SQL的最值得关注的地方之一。在G-CORE研究语言中，你可以将两个图结合起来，然后添加新元素（节点和关系），构成第三个图。作者着眼于“在现有图上构建”。G-CORE（比如Cypher for Apache Spark）只针对不可变数据进行操作，因此这种方法中的第三个图实际上是前两个图的副本加上任何新数据。但数据库是可变存储系统。在Neo4j中，我们开始将这种“两个图加新数据”设计模式的可变存储系统称为全图（omnigraph）。它是视图和基本图的组合，在SQL中没有相对应的，因为SQL并不构造拥有任何显式关系的数据，只有值调控的链接（外来键）。GQL视图如同SQL视图，让你可以查看源自基本表上函数的数据。该视图的任何更新都将写入到基本表。GQL基本图（如同SQL基表表）让你可以直接存储和读取数据。但是GQL“全图”将是这样一个图：一些数据通过其他图（包括其他视图）的视图得出的，一些数据是新的、是相应图所特有的（基本数据）。这就有可能在预先存在的图中的元素之间添加关系，但是这些关系仅存在于“叠加”全图中。这种安排好比SQL中基本表和派生表的命名组合，由于外来键和链接表关系形成的内在图被组合在一起。我们认为，称之为图更合乎自然，使用图形查询语言来定义和查询它更自然。GQL项目的工作将于本月晚些时候在坦桑尼亚阿鲁沙召开的SQL/GQL标准委员会ISO/IEC JTC 1 SC 32/WG3的下一次会议上全面开始。现阶段无法表明第一个可实施版本的GQL何时问世，但很有可能在2020年下半年之前制定某个相当完整的草案。10月9日周三将举行GQL社区更新互联网大会，由LDBC主席Peter Boncz和WG3召集人Keith Hare共同主持。这次会议将讨论不同的主题和工作流程，包括针对属性图模式和现有语言分析的两个LDBC“特别任务组”安排的社区工作。此前，LDBC的理事会已决定为支持GQL的社区工作充当组织中心，充分发挥LDBC与WG3的正式联络机制。已设想使用正式的指称语义来协助提高GQL规范的质量和准确性，并依托在爱丁堡和华沙开展的类似工作，为Cypher的一部分（包括值得关注的Cypher.PL可执行语义项目，用Prolog编写）定义正式语义。随着时间的推移，也很有可能会开始开发用于语法工具和一致性测试的开源软件，以支持官方规范，就像openCypher项目那样。GQL有望成为属性图的关键性标准：在这个世纪，数据管理领域最激动人心、最强大的产品类别之一已在业界扎稳了脚跟。数据库社群欢迎加入，群主微信：guanhongyan1023（备注任职单位+职位），否则不予通过